Modern enterprises typically use a lot of software systems in a system landscape. In most current system landscapes, many components are directly connected in a point-to-point connection. To facilitate communications, interfaces are developed between two systems so that a sender system can send a document to a receiver system via an interface. Those interfaces typically are hardwired into the application components and individual mappings programs. Because interfaces are required between any two systems, the growth of the number of computer systems results in a complicated network of connections. Under these conditions, managing the collaborative sharing of information is difficult. Therefore, companies face an increasing need for integration of and collaboration among their information and enterprise software systems.
Process integration has been implemented to provide a solution to this increasing need. Process integration typically relies on central application servers to deal with the interplay between intra- and inter-component processes of different systems regarding modeling, transaction management, configuration, monitoring and extensibility. These central application servers, for example, (Enterprise Application Integration hubs) are connected to all systems in a system landscape, and route the exchanged messages between different systems and map the messages between the systems' formats. The communication with the central application servers is typically implemented in a message exchange framework based on SOAP/XML technology. The message exchange framework provides a platform that allows different interfaces to communicate using a uniform technology and promotes overall clarity and reduces maintenance effort. This central hub approach has several shortcomings. First, the hubs can only route a message based on the information contained in the message. Frequently, the messages don't contain enough information for correct routing decisions. Second, a source message can only be mapped into a target message format if it already contains all required information, which often is not the case as well. As a result, the sender system interfaces/messages often still have to be adapted for each receiver system
Furthermore, customers keep complaining about high total cost of ownership (TCO) and high total cost of development (TCD) in operations of a process integration product. The main reason for the complaints is that the current application servers provided by software venders have severe limitations. For example, current application servers typically lack programming model and infrastructure for remote and peer-to-peer communication that provides uniform support for all communication channels, for managing the state of conversations with remote components, or for monitoring and error handling. Further, the existing infrastructure only provides disparate solutions for some of these capabilities for some channels and gaps are closed by patch solutions.
Moreover, the business and integration logic is often closely interwoven such that adapting to a new integration process often requires significant changes to the core business logic as well. This leads to a higher TCD for process integration in general and the absence of a unified approach across all applications results in a proliferation of tools and configuration environments, which increases TCO considerably and inhibits scenario-driven configuration. The typical solution to separate business and integration logic uses a framework driven control flow, in which application logic is implemented in business objects and the framework calls on the business objects to perform various functions. However, the drawback of a framework approach is that any logic that does not fit into the predefined framework logic either requires a modification to the framework itself or some “creative” code to lever the limitations of the framework. As the framework drives the application, it has to have a deep knowledge on how applications are built, which contradicts the separation of concerns if the framework and applications are developed by different organizations. This also complicates the enhancement of the framework if adoptions to unforeseen use cases must be supported by the framework. Further, the hidden control logic makes it harder for untrained developers, supporters or customers to understand the overall logic.
Therefore, there is a need for a system and method that provides a communication mechanism that separates business and integration logic and reduces the cost of adding new communication channels.